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ABSTRACT 

Cascading Style Sbeets have been introduced by the W3C as 
a mechanism for controlling the appearance of HTML docu- 
ments. In this paper, we demonstrate how constraints provide 
a powerful unifying formalism for declaratively understand- 
ing and specifying style sbeets for web documents. With con- 
straints we can naturally and declaratively specify complex 
behaviour such as inberitance of properties and cascading of 
conflicting style rules. We give a detailed description of a 
constraint-based style sbeet model, CCSS, which is compat- 
ible with virtually all of the CSS 2.0 specification. It allows 
more flexible specification of layout, and also allows the de- 
signer to provide multiple layouts that better meet the desires 
of the user and environmental restrictions. We also describe a 
prototype extension of the Amaya browser that demonstrates 
the feasibility ofCCSS. 

KEYWORDS: Constraints, HTML, style sbeets, CSS, Cas- 
cading Style Sbeets, CCSS, World Wide Web, page layout, 
Cassowary 

INTRODUCTION 

Since the inception of the Web tbere has been tension be- 
tween the "stracturalists" and the "designers." On one hand, 
stracturalists believe tbat a Web document sbould consist 
only of the content itself and tags indicating the logical struc- 
ture of the document, with the browser free to determine the 
document's appearance. On the otber band, designers (un- 
derstandably) want to specify the exact appearance of the 
document ratber than leaving it to the browser. 

Witb the recent cbampioning of style skeets by the World- 
Wide-Web Consortium (W3C), tbis debate has resulted in a 



compromise. The web document proper sbould contain the 
content and stractural tags, togetber witb a Unk to one or 
more style sbeets that determine how the document will be 
displayed. Thus, tbere is a clean separation between doc- 
ument stracture and appearance, yet the designer has con- 
siderable control over the final appearance of the document. 
W3C has introduced Cascading Style Skeets, first CSS 1.0 
and now CSS 2.0, for use witb HTML documents. 

Despite the clear benefits of cascading style sbeets, tbere are 
several areas in wbicb the CSS 2.0 standard can be improved. 

• The designer lacks control over the document's appearance 
in environments different from her own. For example, if 
the document is displayed on a monocbrome display, if 
fonts are not available, or if the browser window is sized 
differently, then the document's appearance will often be 
less tban satisfactory. 

• CSS 2.0 has seemingly ad hoc restrictions on layout spec- 
ification. For example, a document element's appearance 
can often be specified relative to the parent of the element, 
but generaUy not relative to otber elements in the docu- 
ment. 

• The CSS 2.0 specification is complex and sometimes vague. 
It relies on procedural descriptions to understand the effect 
of complex language features, such as table layout. This 
makes it difficult to understand how features interact. 

• Browser support for CSS 2.0 is still limited. We conjecture 
that this is due in part to the complexity of the specifica- 
tion, but also because the specification does not suggest a 
unifying implementation mecbanism. 

We argue that constraint-based layout provides a solution to 
all of tbese issues, because constraints can be used to specify 
declaratively the desired layout of a web document. Tbey 
allow partial specification of the layout, which can be com- 
bined with otber partial specifications in a predictable way. 
Tbey also provide a uniform mecbanism for understanding 
layout and cascading. Finally, constraint solving tecbnology 
provides a unifying implementation technique. 



We describe a constraint-based extension to CSS 2.0, called 
Constraint Cascading Style Skeets (CCSS). The extension 
allows the designer to add arbitrary linear arithmetic con- 
straints to the style sheet to control features such as object 
placement, and finite-domain constraints to control features 
such as font properties. Constraints may be given a strengtb, 
reflecting their relative importance. They may be used in 
style rules in which case rewritings of the constraint are cre- 
ated for each applicable element. Multiple style sbeets are 
available for the same media type (e.g., paper vs. screen) with 
preconditions on the style sbeets determining which are ap- 
propriate for a particular environment and user requirements. 

Our main tecbnical contributions are: 

• A demonstration that constraints provide a powerful uni- 
fying formalism for declaratively understanding and spec- 
ifying CSS 2.0. 

• A detailed description of a constraint-based style sbeet 
model, CCSS, which is compatible with virtually all of 
the CSS 2.0 specification. CCSS is a true extension of 
CSS 2.0. It allows more flexible specification of layout, 
and also allows the designer to provide multiple layouts 
that better meet the desires of the user and environmental 
restrictions. 

• A prototype extension of the Amaya browser that demon- 
strates the feasibifity of CCSS. The prototype makes use 
of the sopbisticated constraint solving algoritbm Casso- 
wary [4] and a simple one-way binary acycUc finite-domain 
solver based on BAFSS [12]. 

BACKGROUND 

Cascading Style Skeets (CSS 1.0 in 1997 and CSS 2.0 in 
1998) were introduced by the W3C in association with the 
HTML 4.0 standard. In this section we review relevant as- 
pects of CSS 2.0 [6] and HTML 4.0 [9]. 

CSS 2.0 and HTML 4.0 provide a comprehensive set of 
"style" properties for each type of HTML tag. By setting 

the value of these properties the document autbor can control 
how the browser will display each element. Broadly speak- 
ing, properties eitber specify how to position the element 

relative to other elements, e.g. text-indent, margin, or 
f loat, orbow to display the element itself, e.g. f ont-size 
or color. 

Altbougb the autbor can directly annotate elements in the 
document with style properties, CSS encourages the autbor 
to place this information in a separate style sbeet and then 
Unk or import that file. Thus, the same document may be 
displayed using different style sbeets and the same style sbeet 
may be used for multiple documents, easing maintenance of 
a uniform look for a web site. 

A style sbeet consists of rules. A rule has a selector that 
specifies the document elements to which the rule applies, 
and declarations that specify the stylistic effect of the rule. 
The declaration is a set of propertylvalue pairs. Yalues may 



<HTML> <HEAD> 

<TITLE>Simple Example</TITLE> 
<LINK REL="stylesheet" 

HREF="simple . css" 

TYPE="text/css"> </HEAD> 

<BODY> 

<H1 ID=h>Famous Quotes</Hl> 
<P ID=p> At a party at Blenheim Palace, 
Lady Astor said to 
Winston Churchill: 
<BLOCKQUOTE ID=ql> 
If I were married to you, I'd put 
poison in your coffee. And he responded: 
<BLOCKQUOTE ID=q2> 

If you were my wife, I'd drink it . 
</BLOCKQUOTE> 
</BLOCKQUOTE> 
</P> 
</BODY> 
</HTML> 

Figure 1 : Example HTML Document 

be eitber absolute or relative to the parent element's value. 

For instance, the style sheet 

Hl { font-size: 13pt } 
P { font-size: llpt } 
BLOCKQUOTE { font-size: 90% } 

Figure 2: simple.css 

has tbree rules. The first uses the selector Hl to indicate that 
it applies to all elements with tag Hl and specifies that tbose 
first-level beadings sbould be displayed using a 13 pt font. 
The second rule specifies that paragrapb elements sbould use 
an 11 pt font. The tbird rule specifies the appearance of 
text in a blockquote, specifying that the font-size sbould 
be 90% of that of the surrounding element. 

We can use this style sbeet to specify the appearance of the 
HTML document sbown in Figure 1 . Notice the Unk to the 
style sbeet and that we have included an ID attribute for aU 
elements since we will refer to them later ' 

Selectors come in tbree main flavors: type, attribute, and 
contextual. Tbese may be combined to give more complex 
selectors. We have already seen examples of a type selector 
in which the document elements are selected by giving the 
"type" of tbeir tag. For example, the type-selector Hl refers 
to all first-level beading elements. The wildcard type, "*", 
matcbes all tags. 

Attribute selectors cboose elements based on the values of 
two attributes that each element in the document tree may 

'Marking all elements with ID attributes defeats the modularity and re- 
use benefits of CSS; we over-use ID tags bere strictly as an aid to discussing 

our examples. 
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Figure 3: Document tree for the HTML of Figure 1 . 

optionally provide: CLASS and ID. Multiple elements may 
specify the same class value, while the id value should be 
unique. 

Selection based on the class and id attributes provides con- 
siderable power. By using class attributes and selectors, the 
autbor can categorize various document elements into groups 
and then apply different formatting to each of the groups. 
Similarly, by using ID attributes and selectors, the autbor can 
single out document elements f or special formatting and then 
refer to them from the style sbeet. Elements with a specific 
class value are selected using the syntax " . class", wMle in- 
stance ids are selected with "#id". 

Contextual selectors allow the autbor to take into account 
wbere the element occiu's in the document, i.e. its context. 
They are based on the document's document tree, which cap- 
tures the recursive structure of the tagged elements. A con- 
text selector allows selection based on the element's ances- 
tors in the document tree. 

For instance, the preceding document has the document tree 
sbown in Figure 3. If we want to ensure the iimermost block 
quote does not have its size reduced relative to its parent, we 
could use 

BLOCKQUOTE BLOCKQUOTE { font-size: 100% } 

Less generally, we could individually override the font size 
for the second blockquote by using a rule with an lo se- 
lector: 

#Q2 { font-size: 100% } 

Many style properties are inberited by default from the el- 
ement's parent in the document tree. GeneraUy speaking, 
properties that control the appearance of the element itself, 
such as font-size, are inberited, wbile tbose that control 
its positioning are not. 

As anotber example, consider the HTML document sbown in 
Figure 4. We can use a style sheet to control the widtb of the 
columns in the table. For example, table.css (Figure 5) 
contains rules specifying that the elements of the classes 
medcol and thxncol have widtbs 30% and 20% of tbeir 



<HTML> <HEAD> 

<TITLE>Table Example</TITLE> 
<LINK REL="stYlesheet" 

HREF="table . css" 

TYPE="text/css"> </HEAD> 

<BODY> 
<TABLE ID=t> 
<COL ID=cl CLASS=medcol> 
<COL ID=c2> 

<COL ID=c3 CLASS=thincol> 
<TR> 
<TD C0LSPAN=2> 

<IMG ID=il SRC="back . gif "></TD> 
<TD><IMG ID=i2 SRC= " next . gif " ></TD> 
</TR> 
<TR> 
<TD>Textl</TD> 
<TD>Text2</TD> 
<TD>Text3</TD> 
</TR> 
</TABLE> 
</BODY> 
</HTML> 

Figure 4: Example HTI\/IL Document 

parent tables, respectively. (Note the use of the class selector 
"." syntax). 

.medcol { width: 30% } 
.thincol { width: 20% } 

Figure 5: tabie . css 

One of the key features of CSS is that it allows multiple style 
sbeets for the same document. Thus a document migbt be 
displayed in the context of the autbor's special style sbeet for 
tbat document, a default company style sbeet, the user's style 
sbeet and the browser's default style sbeet. This is bandled 
in CSS by cascading the style sbeets, permitting each of the 
sbeets to affect the final rendering. 

Cascading, inberitance, and multiple style sbeet rules matcb- 
ing the same element may mean that tbere are conflicts among 
the rules as to what value a particular style property for that 
element sbould take. The exact details of which value is cho- 
sen are complex. Witbin the same style sheet, inberitance is 
weakest, and rules with more specific selectors are preferred 
to tbose with less specific selectors. For instance, each of the 
rules 

#Q2 { font-size: 100% } 

BLOCKQUOTE BLOCKQUOTE { font-size: 100% } 

is more specific than 

BLOCKQUOTE { font-size: 90% } 

Among style sbeets, the values set by the designer are pre- 
ferred to tbose of the user and browser, and for otberwise 



equal conflicting rules, those in a style sheet that is imported 
or Unked first have priority over those subsequently imported 
or linked. However, a style sheet author may also annotate 
rules with the strength ! important, which will override this 
behavior. In CSS 2.0, forrules designated with strengtb ! im- 
portant, user-specified rules take priority over designer- 
specified rules.^ 

Despite its power, CSS 2.0 still has a number of limitations. 
One Umitation is that a style property may only be relative to 
the element's parent, not to other elements in the document. 
This can result in clumsy specifications, and makes some rea- 
sonable layout constraints impossible to express. For exam- 
ple, it is not possible to require that all tables in a document 
have the same widtb, and that this should be the smallest 
widtb that allows aU tables to have reasonable layout. With 
CSS 2.0, one can only give the tables the same fixed size or 
the same fixed percentage widtb of tbeir parent element. 

The otber main limitation is that it is difficult f or the designer 
to write style sbeets that degrade gracefully in the presence 
of unexpected browser and user limitations and desires. For 
instance, the autbor has Uttle control over what bappens if 
the desired fonts sizes are not available. Consider the style 
sbeet simple.css again. Imagine that only 10 pt, 12 pt, and 
14 pt fonts are available. The browser is free to use 12 pt and 
10 pt for beadings and paragrapbs respectively, or 14 pt and 
12 pt, or even 12 pt and 12 pt. Part of the problem is that 
rules always give definite values to style properties. When 
different style sbeets are combined only one rule can be used 
to compute the value. Thus a rule is eitber on or off, leading 
to discontinuous behavior when style sbeets from the autbor 
and user are combined. For instance, a sight-impaired user 
migbt specify that all font sizes must be greater than 1 1 pt. 
However, if the designer has cbosen sufficiently large fonts, 
the user wisbes to use the designer's size. Tbis is impossible 
in CSS 2.0. 

CONSTRAINT CASCADING STYLE SMEETS 

Our solution to tbese problems is to use constraints for spec- 
ifying layout. A constraint is simply a statement of a rela- 
tion (in the matbematical sense) that we would Uke to have 
hold. Constraints have been used for many years in inter- 
active grapbical applications for such tbings as specifying 
window and page layout. They allow the designer to specify 
what are the desired properties of the system, ratber than how 
tbese properties are to be maintained. The major advantage 
of using constraints is that they allow partial specification of 
the layout, which can be combined with otber partial spec- 
ifications in a predictable way. In this section, we describe 
our constraint-based extension to CSS 2.0, called Constraint 
Cascading Style Skeets (CCSS). 

One complication in the use of constraints is that they may 

^TMs seemingly-inconsistent relative ordering of the ! important 
preferences was cbanged from CSS 1.0 to guarantee that the user has ulti- 
mate control over the appearance of a document. 



conflict. To allow for this we use the constmint kiemrcky 
formaUsm [3]. A constraint Uierarcby consists of a collec- 
tion of constraints, each labeled with a strengtb. Tbere is a 
distinguisbed strengtb labeled REQU1RED: such constraints 
must be satisfied. The otber strengtbs denote preferences. 
Tbere can be an arbitrary number of such strengtbs, and con- 
straints with stronger strengtbs are satisfied in preference to 
ones with weaker strengtbs. Given a system of constraints, 
the constraint solver must find a solution to the variables that 
satisfies the required constraints exactly, and that satisfies the 
preferred constraints as well as possible, giving priority to 
tbose more strongly preferred. The cboice of solution de- 
pends on the comparator function used to measure how well 
a constraint is satisfied. In our examples we sball assume the 
weigkted-sum-better comparator that sums the errors in sat- 
isfying each of the constraints, weigbting each error by the 
strengtb of that constraint. By using an appropriate set of 
strengtb labels we can model the behavior of CSS 2.0. 

A Constraint View of CSS 2.0 

Hierarchical constraints provide a simple, unifying way of 
understanding much of the CSS 2.0 specification. This view- 
point also suggests that constraint solvers provide a natu- 
ral implementation technique. Each style property and the 
placement of each element in the document can be mod- 
eled by a variable. Constraints on tbese variables arise from 
browser capabilities, default layout behavior arising from the 
type of the element, from the document tree structure, and 
from the application of style rules. The final appearance of 
the document is determined by finding a solution to tbese 
constraints. 

The first aspect of CSS 2.0 we consider is the placement of 
the document elements (i.e., page layout). Tbis can be mod- 
eled using linear aritbmetic constraints. To Ulustrate this, we 
examine table layout — one of the most complex parts of CSS 
2.0. The key difficulty in table layout is that it involves infor- 
mation flowing bottom-up (e.g. from elements to columns) 
and top-down (e.g. from table to columns). The CSS 2.0 
specification is procedural in nature, detailing how this oc- 
curs. By using constraints, we can declaratively specify what 
the browser sbould do, ratber than how to do it. Furtbermore, 
the constraint viewpoint allows a modular specification. For 
example, to understand how a complex nested table sbould 
be laid out, we simply coUect the constraints for each com- 
ponent, and the solution to these is the answer. With a pro- 
cedural specification it is much barder to understand such 
interaction. 

Consider the style sbeet table . css (Figure 5) and the as- 
sociated HTML document (Figure 4). The associated layout 
constraints are sbown in Figure 6. The notation #id[prop] 
refers to the value of the property prop for the presentation 
element corresponding to the document element with ID id? 
Since we are dealing with a table, the system automatically 

'We use associative array-like syntax for referring to properties of el- 
ements to avoid the confusion that the altemative ".selector" form would 



(1) 


#i[width] = #cl[width] + 




(1) 


#/i[font-size] e {9, 10, 12, 16, 36, 72} 


REQUIRED 




#c2[width] + #c3[width] 


REQUIRED 


(2) 


#p[font-size] G {9, 10, 12, 16, 36, 72} 


REQUIRED 


(2) 


#cl[width] > width("Textl") 


REQUIRED 


(3) 


#gl[font-size] € {9, 10, 12, 16, 36, 72} 


REQUIRED 


(3) 


#c2[width] > width("Text2") 


REQUIRED 


(4) 


#52[font-size] e {9, 10, 12, 16, 36, 72} 


REQUIRED 


(4) 


#c3[width] > width("Text3") 


REQUIRED 


(5) 


#/i[font-size] = 13 


DESIGNER 


(5) 


#c3[width] > #'«2[width] 


REQUIRED 


(6) 


#p[font-size] = 11 


DESIGNER 


(6) 


#cl[wiQtnj + #c2[wiatnj > ^zl[wiatiij 


REQUIRED 


(7) 


#gl[font-size] = 0.9 * #j3[font-size] 


DESIGNER 


(7) 


#t[width] = 0 


WEAK 


(8) 


#g2[font-size] = 0.9 * #gl[font-size] 


DESIGNER 


(8) 


#cl[width] = 0.3 * #t[width] 


DESIGNER 








(9) 


#c3[width] = 0.2 * #t[width] 


DESIGNER 


Figure 7: Example finite domain constraints 




Figure 6: Example layout constraints 











creates a constraint (1) relating the column widths and table 
widtb."* Similarly, tbere are automatically created constraints 
(2-6) tbat eacb column is wide enougb to bold its content, and 
(7) that the table has minimal widtb. Constraints (8) and (9) 
are generated from the style sheet. Notice the different con- 
straint strengtbs: from weakest to strongest they are weak, 
DESIGNER and REQUIRED. Since REQUIRED is stronger 
than DESIGNER, the column will always be big enougb to 
hold its contents. The weak constraint #t[width] = 0 
cannot be satisfied exactly; the effect of minimizing its er- 
ror will be to minimize the width of the table, but not at the 
expense of any of the other constraints. 

These constraints provide a declarative specification of what 
the browser sbould do. This approacb also suggests an im- 
plementation strategy: to lay out the table, we simply use 
a linear arittunetic constraint solver to find a solution to the 
constraints. The solver implicitly takes care of the flow of in- 
formation in both directions, from the fixed widths of the im- 
ages upward, and from the fixed width of the browser frame 
downward. 

Linear aritbmetic constraints are not the only type of con- 
straints implicit in the CSS 2.0 specification. Tbere are also 
constraints over properties that can take only a finite num- 
ber of different values, including font size, font type, font 
weigbt, and color Such constraints are called finite domain 
constraints and have been widely studied by the constraint 
programming community [14]. Typically, they consist of a 
domain constraint for each variable giving the set of values 
the variable can take (e.g., the set of font sizes available) and 
required aritbmetic constraints over the variables. 

As an example, consider the constraints arising from the doc- 
ument in Figure 1 and style sheet simple.css (Figure 2). 
The corresponding constraints are shown in Figure 7. The 
domain constraints (1-4) reflect the browser's available fonts. 
The remaining constraints result from the style sheet rules. 
Note that the tbird rule generates two constraints (7) and (8), 
one for each block quote element. 



#;i[font-size] = 13 
#p[font-size] = 11 
#gl[font-size] = 0.9 * #p[font-size] 
#g2[font-size] = 0.9 * #gl[font-size] 
^^^[font-size] = 1.0 * #gl[font-size] 



(designer, 0, 0, 1) 
(designer, 0, 0, 1) 
(designer, 0,0, 1) 
(designer, 0, 0, 1) 
(designer, 0, 0, 2) 



cause due to CSS's pre-existing use of "." as a class-name prefix in selectors 
of rules. 

'^For simplicity, we ignore margins, borders and padding in this example. 



Figure 8: Example of overlapping rules 

Both of the preceding examples have carefuUy avoided one 

of the most complex parts of the CSS 2.0 specification: what 
to do when multiple rules assign conflicting values to an el- 
ement's style property. As discussed earlier, there are two 
main aspects to this: cascading several style sheets, and con- 
flicting rules witbin the same style sheet. 

We can model both aspects by means of hierarchical con- 
straints. To do so we need to refine the constraint strengtbs 
we have been using. Apart from REQUIRED, each strengtb is 
a lexicographically-ordered tuple 

(cs, i, c, t). 

The first component in the tuple, cs, is the constraint im- 
portance and captures the autbor-suggested strengtb of the 
constraint and its position in the cascade. The constraint 
importance is one of WEAK, BROWSER, USER, DESIGNER, 
DESIGNER-IMPORTANT, or USER-IMPORTANT (orderedfrom 
weakest to strongest). The importance weak is used for au- 
tomatically generated constraints only. The last tbree com- 
ponents in the tuple capture the specificity of the rule that 
generated the constraint: i is the number of ID attributes, c 
is the number of CLASS attributes, and t is the number of tag 
names in the rule (i.e., the depth of the contextual selection). 

As an example, consider the constraints arising from the doc- 
ument in Figure 1 with the style sheet 

Hl { font-size: 13pt } 

P { font-size: llpt } 

BLOCKQUOTE { font-size: 90% } 

BLOCKQUOTE BLOCKQUOTE { font-size: 100% } 

The constraints and tbeir strengtbs for those directly gener- 
ated from the style sbeet rules are shown in Figure 8. Be- 
cause of its greater weigbt, the last constraint listed will 
dominate the second to last one, giving rise to the expected 



BODY[font-size] = 12 
#/i[font-size] = BODY[font-size] 
#p[font-size] = BODY[font-size] 
#gl[font-size] = #p[font-size] 
#g2[font-size] = #(jl[font-size] 
#Ql[font-size] = 8 
#g2[font-size] = 8 



(browser, 0, 0, 0) 

(WEAK, 0,0,0) 
(WEAK, 0,0,0) 
(WEAK, 0, 0, 0) 

(WEAK, 0,0,0) 

(designer, 0, 0, 1) 
(designer, 0, 0, 1) 



Figure 9: Example of inberitance rules 

behavior — that the longer contextual selection of a block- 
quote within a blockquote will govem the appearance of 
those nested blockquotes. 

The remaining issue we must deal witb is inberitance of style 
properties sucb as font size, and the expression of tbis inber- 
itance witbin our constraint formalism. For eacb inberited 
property, we need to automatically create an appropriate con- 
straint between eacb element and its parent. At first glance, 
tbese sbould simply be WEAK equality constraints. Unfor- 
tunately, tbis does not model the inberent directionality of 
inberitance. 

For instance, imagine displaying the document in Figure 1 
witb the style sbeet 

BLOCKQUOTE { font-size: 8pt } 

wbere the default font size is 12 pt. The scbeme outlined 
above gives rise to the constraints sbown in Figure 9. One 
possible weighted-sum-better solution to tbese constraints is 
tbat the beading is in 12 pt and the rest of the document 
(including the paragrapb) is in 8 pt. The problem is tbat 
the paragrapb element #p has "inberited" its value from its 
child, the blockquote element #gl. 

To capture the directionality of inberitance we use read- 
only annotations [3] on variables tbat represent inberited at- 
tributes. Intuitively, a read-only variable w in a constraint c 
means tbat c sbould not be considered until the constraints 
involving u as an ordinary variable (i.e., not read-only) have 
been used to compute u's value. 

To model inberitance, we need to add the inberitance equali- 
ties witb constraint importance of WEAK, and mark the vari- 
able corresponding to the parent's property as read-only. The 
read-only annotation ensures tbat the constraints are solved 
in an order corresponding to a top-down traversal of the doc- 
ument tree. Tbus, the above example modifies the constraints 
in Figure 9 so that each font size variable on the rigbt band 
side has a read-only annotation. 

Extending CSS 2.0 

We have seen how we can use bierarcbical constraints to pro- 
vide a declarative specification for CSS 2.0. Tbere is, how- 
ever, anotber advantage in viewing CSS 2.0 in this ligbt. The 
constraint viewpoint suggests a number of natural extensions 



that overcome the expressiveness limitations of CSS 2.0 dis- 
cussed previously. We call tbis extension CCSS — Constraint 
Cascading Style Sbeets. 

As the above examples indicate, virtually all autbor and user 
constraints generated from CSS 2.0 eitber constrain a style 
property to take a fixed value, or relate it to the parent's 
style property value. One natural generalization is to allow 
more general constraints sucb as inequalities. Anotber natu- 
ral generalization is to allow the constraint to refer to otber 
variables — ^botb variables corresponding to non-parent ele- 
ments and to "global" variables. 

In CCSS, we allow constraints in the declaration of a style 
sbeet rule. The CSS-style attribute : value pair is re- 
interpreted in tbis context as the constraint attribute = 
value. Weprependall constraint rules witb the constraint 
pseudo-property so tbat CCSS is backwards compatible witb 
browsers supporting only CSS. In a style sbeet rule, the con- 
straintcanreferto attribute sofparentandleft-sibling. 
For example: 

P { constraint: 

font-size <= 

(parent [parent ] ) [font-size] + 2 } 

is a rule tbat appfies constraints tbat relate the font-size of a 
paragrapb element to the font-size of its grandparent element. 

CCSS style sbeets also allow the autbor to introduce global 
constrainable variables using a new @variable directive. 
A variable identifier is lexicaUy the same as a CSS id at- 
tribute. The autbor can express constraints among global 
constrainable variables and element style properties using a 
new @constraint directive. Tbere are also various global 
built-in objects (e.g., Browser) witb tbeir own attributes that 
can be used. 

These extensions add considerable expressive power. For in- 
stance it is now simple to specify tbat all tables in the docu- 
ment have the same widtb, and tbat tbis is the smallest widtb 
tbat allows all tables to have a reasonable layout: 



@variable table-width; 
TABLE { constraint: width 



table-width 



Similarly we can specify two columns cl and c2 in the same 
(or different) tables have the same widtb (the smallest for 
reasonably laying out botb): 

@constraint #cl [widtb] = #c2 [widtb] ; 

It also allows the designer to express preferences in case the 
desired font is not available. For example adding 

Hl { constraint: font-size >= 13pt } 
P { constraint: font-size >= llpt } 

to simple.css (Figure 2) will ensure tbat larger fonts are 
used if 13 pt and 1 1 pt fonts are not available. 

Finally, a sight-impaired user can express the strong desire to 
have all font sizes greater tban 12 pt: 



* {constraint: font-size >= 12pt limportant} 

As long as the font size of an element is 12 pt or larger it will 
not be cbanged, but smaller fonts will be enlarged. 

Note that the style sheet autbor is not allowed to explicitly 
specify a constraint to be required as this would admit the 
possibiUty of an unsatisfiable constraint system. Instead, RE- 
QUIRED constraints are generated implicitly for capturing re- 
lationsbips inberent in the structure of the layout, such as a 
table's widtb being the sum of the widtbs of its columns. 

Providing inequality constraints allows the author to con- 
trol the document appearance more precisely in the context 
of browser capabilities and user preferences. Additionally, 
CCSS allows the autbor to give altemate style sbeets for the 
same target media. Each style sbeet can list preconditions 
for their applicability using a new @precondition direc- 
tive. For efficiency, the precondition can only refer to vari- 
ous pre-defined variables. The values of tbese variables will 
be known (i.e. they wiU have specific values) at the time the 
precondition is tested. For example: 

@precondition Browser [ f rame-width] >= 800px; 
@precondition ColorMonitor = True; 

We extend the style sbeet @ import directive to permit listing 
multiple style sbeets per line, and the first applicable sbeet is 
used (the otbers are ignored). If no style sbeet's precondi- 
tions hold, none are imported. Consider the example direc- 
tive 

gimport "wide.css", "tall.css", "small.css"; 

If wide . css's preconditions fail, but tall.css's succeed, 
the layout uses tall . css. If, through the course of the user 
resizing the top-level browser frame, wide . css's precondi- 
tions later become satisfied, the layout does not switcb to that 
style sbeet unless tall.css's preconditions are no longer 
satisfied. That is, the cboice among style sbeets listed with 
one directive is only revisited when a currently-used style 
sbeet is no longer applicable. 

As an example, consider a style sbeet for text with pictures. 
If the page is wide, the images sbould appear to the rigbt of 
the text; if it is narrow, they sbould appear witbout text to the 
left; and if it is too small, the images sbould not appear at all. 
Tbis can be encoded as: 

/* wide.css */ 

Sprecondition Browser [ f rame-width] > 550px; 
IMG { float: right} 

/* tall.css */ 

Sprecondition Browser [ f rame-width] <= 600px; 

Sprecondit ion Browser [ f rame-height ] > 550px; 
IMG { clear: both; f loat : none} 

/* small . css */ 

IMG { display: none } 



Preconditions become even more expressive in the presence 
of support for CSS positioning [10] and a generalized f low 
property [7]. 

IMPLEMENTATION 
Prototype Web Browser 

We have implemented a representative subset of CCSS to 
demonstrate the additional expressiveness it provides to web 
designers. Our prototype is based on version 1.4a of Amaya 
[8], the W3 Consortium's browser. Amaya is built on top of 
Thot, a structured document editor, and has partial support 
for CSSl. Amaya is exceptionally easy to extend in some 
ways (e.g., adding new HT]V[L tags), and provides a stable 
base from which to build. 

Our support for constraints in Amaya covers the two main 
domains for constraints that we have discussed: table widtbs 
(for illustrating page layout relationsbips) and font sizes (for 
illustrating the solution of systems involving inberited at- 
tributes). In our prototype, HTML and CSS statements can 
contain constraints and declare constrainable variables. In 
HT]y[L statements, constrainable variables, in addition to 
specific values, can be attacbed by name to element attributes 
(e.g., to the "widtb" of a table column). When the constraints 
of the document force the values assigned to variables to 
cbange, the browser updates its rendering of the current page, 
much as it does when the browser window is resized (wbicb 
often caused the re-solve in the first place). 

We have also extended Amaya to support preconditions on 
style sbeets and the generalized "@import" CCSS rule. The 
performance when switcbing among style sbeets is similar to 
a reload, and when the style sbeets are cacbed on disk, per- 
formance is good even when switcbing style sbeets during an 
interactive resize. (It may be useful to provide background 
pre-fetching of alternate style-sbeets to avoid latency when 
they are first needed.) See Figure 10 for screen sbots of an ex- 
ample using our prototype's support for both table layout and 
preconditions. As the support for CSS improves in browsers, 
more significant variations will be possible tbrougb the use 
of our @precondition and extended @import directives. 

We compared the performance of our prototype browser to 
an unmodified version of Amaya 1 .4a, both fully optimized, 
running on a PII/400 displaying across a 10Mbit network to a 
Tektronix XII server on the same subnet. Our test case was 
a smaU example on local disk using seven style sbeets. We 
executed 100 re-loads, and measured the total wall time con- 
sumed. The unmodified browser performed each re-load and 
re-render in 190 ms, wbile our prototype took only 250 ms 
even when sized to select the last altemative style sbeet in 
each of tbree gimport directives. This performance penalty 
is reasonable given the added expressiveness and features the 
prototype provides. 

One of the most important benefits of re-framing CSS as con- 
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Figure 10: Screen shots of our prototype browser. In the view on the left, a narrow style sheet is in effect because 
the browser wjdth < 800 pixels, while on the right a wide style sheet is used. Interactively changing the browser width 
dynamically switches between these two presentations. In both figures, the first column is | the width of the second 
column, which is twice the width of the last column. On the left, the table consumes 1 00% of the frame width, but on the 
right, the table width is the browser width minus 200 pixels. Also notice the changes in font size and text alignment. 



straints is that it provides an implementation approacb for 
even the standard CSS features. To simplify our prototype 
and ensure it remains a superset of CSS functionality, we 
currently do not treat old-style declarations as constraints, 
but instead rely on the existing implementation's handling of 
those rules. However, if designed into a browser from the 
beginning, treating all CSS rules as syntactic sugar for un- 
derlying constraints will result in large savings in code and 
complexity. The cascading rules would be completely re- 
placed by the constraint solver's more principled assignment 
of values to variables, and the display engine need only use 
those provided values, and redraw when the solver changes 
the current solution. 

Constraint Solving Algorithms 

While the semantics of the constraints is independent of the 
algorithms used to satisfy them, for interactive applications 
such as a web browser, we nevertheless must select an al- 
gorithm that is capable of efficiently finding solutions to the 
constraints at interactive speeds. Our implementation uses 
two algorithms: Cassowary [4] and a restricted version of 
BAFSS [12]. 

The Cassowary algorithm handles linear arithmetic equality 
and inequality constraints. The collection of constraints may 
include cycles (i.e. simultaneous equalities and inequalities 
or redundant constraints) and conflicting preferences. Cas- 
sowary is an incremental version of the simplex algorithm, a 
well-known and heavily studied technique for finding a so- 
lution to a collection of linear equality and inequality con- 
straints that minimizes the value of a linear expression called 
the objectiye function. However, commonly available im- 
plementations of the simplex algoritfim are not suitable for 
interactive applications such as a web browser. 

Cassowary supports the weighted-sum-better comparator [3] 



for cboosing a single solution from among those that sat- 
isfy all the required constraints. As mentioned earlier, this 
comparator computes the error for a solution by summing 
the product of the strength tuple and the error for each con- 
straint that is unsatisfied. To model the CSS importance 
rules in a hierarchy of constraint strengths, we encode the 
symbolic levels of importance as tuples as well; for exam- 
ple, USER-IMPORTANT is (1,0,0,0,0,0) and browser is 
(0,0,0,0,1,0). Thus, no matter what scalar error a BROWSER 
constraint has, it will never be satisfied if doing so would 
force a USER-IMPORTANT constraint to not be satisfied. Sim- 
ilarly the last three components of the strengtb tuple are en- 
coded as (lO', 10"^, 10*).^ Since the Cassowary toolkit oper- 
ates on constraints with strengths that are a single n-tuple, we 
intemally use 9-tuples to represent strengths — for example, 

(1,0,0,0,0,0,10°, 10\ 10°) 

is the strengtfi of a user-specified limportant constraint 
whose selector only contains a single class name. 

BAFSS uses a dynamic programming approach to handle 
systems of font constraints which are binary (i.e., a constraint 
with two variables) and for which the associated constraint 
graph is acyclic. For the font constraints implied by CSS, 
we are able to simplify the algorithm because all of the con- 
straints relate a read-only size attribute in the parent element 
to the size attribute of a child element. Given this additional 
restriction that all constraints are one-way, the algorithm is 

^This does not exactly match the CSS specificity rules. For example if 
the error in a constraint with strength (WEAK, 0, 0, 1) is 10 times greater 
than the eiTor in a conflicting constraint with strength (WEAK, 0, 0, 2), the 
first constraint will affect the final solution. By cfioosing appropriate error 
functions we can make this unlikely to occur in practice. However, the more 
general constraint hierarchy support may actually permit more desirable in- 
teractions rather than the strict strength ordering imposed by CSS. 



simple: visit the variable nodes in topological order and as- 
sign each a value tbat greedily minimizes the error contribu- 
tion from that variable. 

Both constraint solvers are implemented witbin the Casso- 
wary Constraint Solving Ubrary [1]. 

RELATED WORK 

The most closely related researcb is our earlier work on the 
use of constraints for web page layout [5]. This system al- 
lowed the web page autbor to construct a document com- 
posed of grapbic objects and text. The layout of tbese ob- 
jects and the text font size were described in a separate "lay- 
out sheet" using Unear aritbmetic constraints and finite do- 
main constraints. Like CCSS, layout sbeets had precondi- 
tions, controUing tbeir appUcability. 

The work reported here, which focuses on how to combine 
constraint-based layout with CSS, is complementary to our 
previous researcb. One of the major tecbnical contributions 
here is to provide a declarative semantics for CSS based on 
MerarcMcal constraints; this issue was not addressed in our 
prior work [5]. Tbere are two fundamental differences be- 
tween layout sbeets and CCSS. Layout sbeets are not style 
sbeets in the sense of CSS since they can only be used with a 
single document. Constraints only apply to named elements, 
and there is no concept of a style rule that applies to multiple 
elements — the constraints that are used are exactly the con- 
straints that the autbor has specified. The otber fundamental 
difference between the earlier work [5] and CCSS is that the 
former has no analogue of the document tree. In essence, the 
document is modeled as a flat coUection of objects; tUere is 
no notion of inberitance, and nearly aU layout must be ex- 
plicitly detailed in the layout sheet. 

Cascading Style Sbeets are not the only kind of style sheet. 
The Document Style Semantics and Specification Language 
(DSSSL) is an ISO standard for specifying the format of 
SGML documents. DSSSL is based on Scbeme, and pro- 
vides both a transformation language and a style language. 
It is very powerful but complex to use. More recently, W3C 
has begun designing the XSL style sbeet for use with XML 
documents. XSL is similar in spirit to DSSSL. PSL [13] is 
another style sheet language; its expressiveness lies midway 
between that of CSS and XSL. The underlying application 
model for all tUree is the same: take the document tree of 
the original document and apply transformation rules from 
the style sbeet in order to obtain the presentation view of the 
document, which is then displayable by the viewing device. 
In the case of XSL, the usual presentation view is an HTML 
document wbose elements are annotated with style proper- 
ties. 

None of these other style sbeet languages allow true con- 
straints. Extending any of them to incorporate constraints 
would offer many of the same benefits as it does for CSS, 
namely, the ability to flexibly combine user, browser, and 



designer desires and requirements, and a simple powerful 
model for layout of complex objects, such as tables. The 
simplest extension is to allow constraints in the presentation 
view of the document. (Providing constraints in the transfor- 
mation rules would seem to offer little advantage.) In the case 
of DSSSL a natural way to do this is to embed a constraint 
solver into Scbeme (as in SCWM [2]). In the case of XSL, 
since HTML is often used as the targeted visual rendering 
language, the simplest cbange is to augment that language to 
be KTML with CCSS style properties. Then the XSL trans- 
lator would simply generate HTML and a CCSS style sbeet, 
with a CCSS-enhanced browser still performing the dynamic 
constraint solving, rendering, and interaction. 

Regarding otiier user interface applications of constraints, 
tbere is a long bistory of using constraints in interfaces and 
interactive systems, beginning with Ivan Sutberland's pio- 
neering Sketcbpad system [17]. Constraints have also been 
used in several otber layout applications. IDEAL [18] is an 
early system specifically designed for page layout appUca- 
tions. Harada, Witkin, and Baraff [11] describe the use of 
pbysically-based modeling for a variety of interactive mod- 
eUng tasks, including page layout. TUere are numerous sys- 
tems that use constraints for widget layout [15, 16], while 
Badros [2] uses constraints for window layout. 

CONCLUSIONS AND FUTURE WORK 

We have demonstrated that hierarchical constraints provide a 
unifying, declarative semantics for CSS 2.0 and also suggest 
a simplifying implementation strategy. Furtbermore, view- 
ing CSS from the constraint perspective suggests several nat- 
ural extensions. We call the resulting extension CCSS — 
Constraint Cascading Style Sbeets. By allowing true con- 
straints and style sheet preconditions, CCSS increases the 
expressiveness of CSS 2.0 and, importantly, allows the de- 
signer to write style sbeets that combine more flexibly and 
predictably with user preferences and browser restrictions. 
We have demonstrated the feasibility of CCSS by modifying 
the Amaya browser. However, substantial work remains to 
develop an industrial-strengtbbrowser supporting full CCSS, 
in part because of Amaya's lack of support for CSS 2.0. A 
more complete implementation will be especially useful for 
investigating the important issue of how well the constraint 
systems and solver scale to larger, more complicated designs 
that furtber exploit our constraint extensions. 

Apart from improving the current implementation, we have 
two principal directions for furtber extensions to CCSS. The 
first is to increase the generality and solving capabilities 
of the underlying solver. For example, style sbeet autbors 
sbould be able to arbitrarily annotate variables as read-only 
so that they have greater control over the interactions of 
global variables. Additionally, virtually all CSS properties, 
such as color and font weigbt, could be exposed to the con- 
straint solver once we integrate otber algoritbms into our 
solving toolkit. 



The second extension is to allow "predicate" selectors in 
style sheet rules. These selectors would permit an arbitrary 
predicate to be tested in detennining the applicabiUty of a 
rule to an element in the document structure tree. Predicate 
selectors can be viewed as a generalization of the existing 
selectors; an Hl p selector is applied only to nodes n for 
which the predicate "n[type] = p and 3m parent-of n such 
that m[type] = Hl" bolds. Tbese predicate selectors would 
allow the designer to take into account the attributes of the 
selected element's parents and cbildren, thus, for instance, 
allowing the number of items in a list to affect the appear- 
ance of the list (as in an example used to motivate PSL [13]). 

A final important area for future work is the design, imple- 
mentation, and user testing of grapbical interfaces for writ- 
ing and debugging constraint cascading style sbeets and web 
pages that use them. 

ACKNOWLEDGMENTS 

We tbank Bert Bos and Hakon Lie of the CSS group of the 

W3 Consortium for early feedback on tbese ideas and our 
proposed extensions to CSS. This researcb has been funded 
in part by a US National Science Foundation Graduate Fel- 
lowsMp for Greg Badros and by NSF Grant No. llS-9975990, 
and in part by a grant from the Australian Researcb Council. 

REFERENCES 

1. G. Badros and A. Boming. The Cassowary linear aritb- 
metic constraint solving algoritbm: Interface and im- 
plementation. Tecbnical Report UW-CSE-98-06-04, 
Umversity of Wasbington, Seattle, Washington, June 
1998. 

2. G. Badros and M. Stacbowiak. Scwm — The Scbeme 
Constraints Window Manager. Web page, 1997-1999. 
http://scwm.mit.edu/. 

3. A. Borning, B. Freeman-Benson, andM. Wilson. Con- 
straint hierarchies. Lisp and Symbolic Computation, 
5(3):223-270, September 1992. 

4. A. Boming, K. Marriott, P. Stuckey, and Y. Xiao. Solv- 
ing linear aritbmetic constraints for user interface appli- 
cations. In Proceedings ofthe lOtkACM Symposium on 
User Interface Software and Tecknology, pages 87-96, 
1997. 

5. A. Borning, R. Lin, and K. Marriott. Constraints for the 
web. In Proceedings of 1997 ACM Multimedia Confer- 
ence, pages 173-182, 1997. 

6. B. Bos, H. Lie, C. Lilley, and I. Jacobs. Cascading style 
sbeets, level 2. W3C Working Draft, January 1998. 
http://www.w3 .org/TR/WD-css2/. 

7. B. Bos, D. Raggett, and H. Lie. Frame-based layout via 
style sbeets. W3C Working Draft. http://www.w3.org/ 
TR/WD-Iayout. 



8. W3 Consortium. Amaya web browser software. Web 
page, October 1998. http://www.w3.org/Amaya. 

9. W3 Consortium. HTML 4.0 specification. Tecbnical 
report, W3 Consortium, 1998. http://www.w3.org/TR/ 
REC-htmI40. 

10. S. Furman and S. Isaacs. Positioning HTML elements 
with cascading style sbeets. W3C Working Draft. 
http://www.w3.org/TR/WD-positioning. 

11. M. Harada, A. Witkin, and D. Baraff. Interactive 
pbysically-based manipulation of discrete/continuous 
models. In SIGGRAPM '95 Conference Proceedings, 
pages 199-208, Los Angeles, August 1995. ACM. 

12. R. Lin, K. Marriott, and P. Stuckey. Flexible font-size 
specification in Web documents. In Proceedings ofthe 
22 Australasian Computer Science Conference, Auck- 
land, New Zealand, January 1999. Springer-Verlag. 

13. P. Marden, Jr. and E. Munson. PSL: An alternate ap- 
proacb to style sbeet languages for the world wide web. 
Journal of Universal Computer Science, 4(10), 1998. 
http://www.cs.uwm.edu/ ~ multimedia. 

14. K. Marriott and P. Stuckey. Programming witk Con- 
straints: An Introduction. The MIT Press, 1998. 

15. B. Myers, D. Giuse, R. Dannenberg, B. Yander Zanden, 
D. Kosbie, E. Pervin, A. Mickisb, and P. Marcbal. Gar- 
net: Comprehensive support for grapbical highly in- 
teractive user interfaces. lEEE Computer, November 
1990. 

16. B. Myers, R. McDaniel, R. Miller, A. Ferrency, 
A. Faulring, B. Kyle, A. Mickisb, A. KIimovitski, and 
P. Doane. The Amulet environment: New models for 
effective user interface software deveIopment. lEEE 
Transactions on Software Engineering, 23(6):347-365, 
June 1997. 

17. I. Sutberland. Sketcbpad: A man-machine grapbical 
communication system. In Proceedings of tke Spring 
Joint Computer Conference, pages 329-346. IFIPS, 
1963. 

18. C. van Wyk. A high-level language for specifying pic- 
tures. ACM Transactions on Grapkics, 1(2): 163-182, 
April 1982. 



